This invention relates to a data processing system comprising a host computing device and a network interface device together configured to perform transport stream processing.
In typical computer systems, streaming protocols such as TCP are generally handled in software at a network protocol stack supported at the computer system. This is because handling streaming protocols is expensive to implement in hardware (e.g. at a network interface device) in terms of both processing power and memory requirements. For example, data is transmitted over TCP by encapsulating it in TCP segments that could be dropped, retransmitted and reordered, and as a result a stream of data may not arrive at the receiver in the correct sequence. Thus, TCP streams require that the protocol stack managing the streams can handle out of order packets (which requires a significant amount of storage) and both the receive and transmit paths of a given stream (because the receive and transmit paths of a TCP stream are not independent). It follows that implementing TCP processing in hardware requires significant logic and a large amount of buffer memory to handle out-of-order packets and retain transmitted packets in case retransmission is required.
Nevertheless, due to the potential improvements in latency offered by processing TCP streams at a NIC, network interface devices that can perform TCP processing in hardware at a TCP offload engine (TOE) have been developed. Examples include NICs based on the Chelsio T4 and Broadcom BCM5708C chips. Performing protocol processing at the NIC also opens up the possibility of performing upper layer protocol processing at the NIC so as to further minimise the latency associated with communicating upper layer messages over TCP. This is because the transport layer TCP protocol must generally be processed prior to any upper layer protocols—for example, TCP data packets received at a NIC must be correctly reassembled into an ordered stream so as to allow the payload data of those data packets to be re-formed and the upper layer messages extracted for processing by the upper layer protocol stack. Thus, if TCP processing is performed at a NIC, the upper layer protocol processing can also be moved into hardware at the NIC, and the latency associated with upper layer messaging can potentially be reduced.
However, incorporating both a TCP offload engine and an upper layer protocol accelerator in hardware at a network interface device requires even greater processing power and memory to be present at the NIC. This significantly increases the complexity and cost of the network interface device, especially since bespoke hardware solutions such as FPGAs (field programmable gate arrays) are typically used to provide upper layer message processing specific to a particular application. Furthermore, the complexity of an integrated hardware TCP and upper layer protocol solution generally results in long development times and, since the hardware implementing the TCP offload engine and accelerator cannot generally be reconfigured with the same ease with which an updated software transport library can be installed into a host computer system, it is much more difficult to make changes to a hardware implementation (e.g. to fix bugs).
There is therefore a need for a host computer system and network interface device that can support low latency messaging over an upper layer protocol without requiring the complexity and expense of a TCP offload engine in hardware.